WebCodecs VideoFrame Plane Access: เจาะลึกการจัดการข้อมูลวิดีโอดิบ

เป็นเวลาหลายปีที่การประมวลผลวิดีโอประสิทธิภาพสูงในเว็บเบราว์เซอร์ดูเหมือนเป็นความฝันที่ห่างไกล นักพัฒนามักถูกจำกัดอยู่กับข้อจำกัดขององค์ประกอบ <video> และ 2D Canvas API ซึ่งแม้จะมีประสิทธิภาพ แต่ก็สร้างปัญหาคอขวดด้านประสิทธิภาพและจำกัดการเข้าถึงข้อมูลวิดีโอดิบที่อยู่เบื้องหลัง การมาถึงของ WebCodecs API ได้เปลี่ยนแปลงภูมิทัศน์นี้โดยพื้นฐาน โดยให้การเข้าถึงระดับต่ำไปยังโคเดกสื่อ (media codecs) ที่มีอยู่ในเบราว์เซอร์ หนึ่งในคุณสมบัติที่ปฏิวัติวงการที่สุดคือความสามารถในการเข้าถึงและจัดการข้อมูลดิบของเฟรมวิดีโอแต่ละเฟรมโดยตรงผ่านอ็อบเจกต์ VideoFrame

บทความนี้เป็นคู่มือฉบับสมบูรณ์สำหรับนักพัฒนาที่ต้องการก้าวข้ามการเล่นวิดีโอแบบธรรมดา เราจะสำรวจความซับซ้อนของการเข้าถึง VideoFrame plane, ไขข้อข้องใจเกี่ยวกับแนวคิดต่างๆ เช่น color spaces และ memory layout และให้ตัวอย่างที่ใช้งานได้จริงเพื่อช่วยให้คุณสามารถสร้างแอปพลิเคชันวิดีโอในเบราว์เซอร์เจเนอเรชันถัดไป ตั้งแต่ฟิลเตอร์แบบเรียลไทม์ไปจนถึงงานด้านคอมพิวเตอร์วิทัศน์ที่ซับซ้อน

ข้อกำหนดเบื้องต้น

เพื่อให้ได้ประโยชน์สูงสุดจากคู่มือนี้ คุณควรมีความเข้าใจที่มั่นคงในเรื่อง:

• Modern JavaScript: รวมถึงการเขียนโปรแกรมแบบอะซิงโครนัส (async/await, Promises)
• แนวคิดพื้นฐานเกี่ยวกับวิดีโอ: ความคุ้นเคยกับคำศัพท์ต่างๆ เช่น เฟรม, ความละเอียด และโคเดก จะเป็นประโยชน์
• Browser APIs: ประสบการณ์กับ API เช่น Canvas 2D หรือ WebGL จะเป็นประโยชน์ แต่ไม่จำเป็นอย่างยิ่ง

ทำความเข้าใจเกี่ยวกับ Video Frames, Color Spaces และ Planes

ก่อนที่เราจะเจาะลึกเข้าไปใน API เราต้องสร้างโมเดลความคิดที่มั่นคงเกี่ยวกับลักษณะข้อมูลของเฟรมวิดีโอก่อน วิดีโอดิจิทัลคือลำดับของภาพนิ่ง หรือเฟรม แต่ละเฟรมคือตารางของพิกเซล และแต่ละพิกเซลก็มีสี วิธีการจัดเก็บสีนั้นถูกกำหนดโดย color space และ pixel format

RGBA: ภาษาดั้งเดิมของเว็บ

นักพัฒนาเว็บส่วนใหญ่คุ้นเคยกับโมเดลสี RGBA แต่ละพิกเซลจะถูกแทนด้วยส่วนประกอบสี่ส่วน: แดง (Red), เขียว (Green), น้ำเงิน (Blue) และอัลฟ่า (Alpha - ความโปร่งใส) โดยทั่วไปข้อมูลจะถูกจัดเก็บแบบ interleaved ในหน่วยความจำ ซึ่งหมายความว่าค่า R, G, B และ A สำหรับพิกเซลเดียวจะถูกเก็บไว้ติดต่อกัน:

[R1, G1, B1, A1, R2, G2, B2, A2, ...]

ในโมเดลนี้ ภาพทั้งภาพจะถูกเก็บไว้ในบล็อกหน่วยความจำต่อเนื่องเพียงบล็อกเดียว เราสามารถคิดได้ว่านี่คือการมีข้อมูลเพียง "ระนาบ" (plane) เดียว

YUV: ภาษาแห่งการบีบอัดวิดีโอ

อย่างไรก็ตาม โคเดกวิดีโอไม่ค่อยทำงานกับ RGBA โดยตรง แต่จะนิยมใช้ color spaces แบบ YUV (หรือให้ถูกต้องกว่าคือ Y'CbCr) โมเดลนี้จะแยกข้อมูลภาพออกเป็น:

• Y (Luma): ข้อมูลความสว่างหรือภาพระดับสีเทา ดวงตาของมนุษย์มีความไวต่อการเปลี่ยนแปลงของ luma มากที่สุด
• U (Cb) และ V (Cr): ข้อมูลความเข้มของสี (chrominance) หรือข้อมูลความแตกต่างของสี ดวงตาของมนุษย์มีความไวต่อรายละเอียดสีน้อยกว่ารายละเอียดความสว่าง

การแยกส่วนนี้เป็นกุญแจสำคัญในการบีบอัดที่มีประสิทธิภาพ โดยการลดความละเอียดของส่วนประกอบ U และ V—เทคนิคที่เรียกว่า chroma subsampling—เราสามารถลดขนาดไฟล์ได้อย่างมีนัยสำคัญโดยที่คุณภาพที่รับรู้ได้ลดลงน้อยที่สุด สิ่งนี้นำไปสู่ pixel formats แบบ planar ซึ่งส่วนประกอบ Y, U และ V จะถูกเก็บไว้ในบล็อกหน่วยความจำที่แยกจากกัน หรือที่เรียกว่า "planes"

ฟอร์แมตที่พบบ่อยคือ I420 (ประเภทหนึ่งของ YUV 4:2:0) ซึ่งสำหรับทุกๆ บล็อกพิกเซลขนาด 2x2 จะมี Y samples สี่ตัว แต่มี U และ V samples เพียงอย่างละหนึ่งตัว ซึ่งหมายความว่า U และ V planes จะมีความกว้างและความสูงเป็นครึ่งหนึ่งของ Y plane

การทำความเข้าใจความแตกต่างนี้เป็นสิ่งสำคัญอย่างยิ่ง เพราะ WebCodecs ให้คุณเข้าถึง planes เหล่านี้ได้โดยตรง เหมือนกับที่ตัวถอดรหัส (decoder) ส่งมาให้เลย

อ็อบเจกต์ VideoFrame: ประตูสู่ข้อมูลพิกเซลของคุณ

ส่วนสำคัญของปริศนานี้คืออ็อบเจกต์ VideoFrame มันแทนเฟรมวิดีโอหนึ่งเฟรม และไม่เพียงแต่มีข้อมูลพิกเซลเท่านั้น แต่ยังมีข้อมูลเมตาที่สำคัญอีกด้วย

คุณสมบัติหลักของ VideoFrame

• format: สตริงที่ระบุ pixel format (เช่น 'I420', 'NV12', 'RGBA')
• codedWidth / codedHeight: ขนาดเต็มของเฟรมตามที่จัดเก็บในหน่วยความจำ รวมถึง padding ใดๆ ที่โคเดกต้องการ
• displayWidth / displayHeight: ขนาดที่ควรใช้ในการแสดงผลเฟรม
• timestamp: การประทับเวลาการนำเสนอของเฟรมในหน่วยไมโครวินาที
• duration: ระยะเวลาของเฟรมในหน่วยไมโครวินาที

เมธอดมหัศจรรย์: copyTo()

เมธอดหลักสำหรับการเข้าถึงข้อมูลพิกเซลดิบคือ videoFrame.copyTo(destination, options) เมธอดแบบอะซิงโครนัสนี้จะคัดลอกข้อมูล plane ของเฟรมไปยังบัฟเฟอร์ที่คุณเตรียมไว้

• destination: ArrayBuffer หรือ typed array (เช่น Uint8Array) ที่มีขนาดใหญ่พอที่จะเก็บข้อมูลได้
• options: อ็อบเจกต์ที่ระบุว่าต้องการคัดลอก planes ใดบ้างและโครงสร้างหน่วยความจำของมัน หากไม่ระบุ จะเป็นการคัดลอก planes ทั้งหมดลงในบัฟเฟอร์ต่อเนื่องเดียว

เมธอดนี้จะคืนค่า Promise ที่ resolve ด้วยอาร์เรย์ของอ็อบเจกต์ PlaneLayout หนึ่งอ็อบเจกต์สำหรับแต่ละ plane ในเฟรม แต่ละอ็อบเจกต์ PlaneLayout ประกอบด้วยข้อมูลสำคัญสองส่วน:

• offset: ค่าออฟเซ็ตเป็นไบต์ที่ข้อมูลของ plane นี้เริ่มต้นภายในบัฟเฟอร์ปลายทาง
• stride: จำนวนไบต์ระหว่างจุดเริ่มต้นของแถวพิกเซลหนึ่งกับจุดเริ่มต้นของแถวถัดไปสำหรับ plane นั้น

แนวคิดที่สำคัญอย่างยิ่ง: Stride กับ Width

นี่เป็นหนึ่งในสาเหตุของความสับสนที่พบบ่อยที่สุดสำหรับนักพัฒนาที่ยังใหม่กับการเขียนโปรแกรมกราฟิกระดับต่ำ คุณไม่สามารถสันนิษฐานได้ว่าข้อมูลพิกเซลแต่ละแถวจะถูกจัดเรียงติดกันอย่างแน่นหนา

• Width คือจำนวนพิกเซลในหนึ่งแถวของภาพ
• Stride (หรือเรียกว่า pitch หรือ line step) คือจำนวนไบต์ในหน่วยความจำจากจุดเริ่มต้นของแถวหนึ่งไปยังจุดเริ่มต้นของแถวถัดไป

บ่อยครั้งที่ stride จะมีค่ามากกว่า width * bytes_per_pixel นี่เป็นเพราะหน่วยความจำมักจะถูกเติม padding เพื่อให้สอดคล้องกับขอบเขตของฮาร์ดแวร์ (เช่น ขอบเขต 32 หรือ 64 ไบต์) เพื่อการประมวลผลที่รวดเร็วยิ่งขึ้นโดย CPU หรือ GPU คุณต้องใช้ stride เสมอในการคำนวณตำแหน่งหน่วยความจำของพิกเซลในแถวที่ต้องการ

การไม่สนใจ stride จะทำให้ภาพบิดเบี้ยวหรือผิดเพี้ยนและการเข้าถึงข้อมูลไม่ถูกต้อง

ตัวอย่างที่ 1: การเข้าถึงและแสดงผล Grayscale Plane

มาเริ่มด้วยตัวอย่างที่เรียบง่ายแต่ทรงพลัง วิดีโอส่วนใหญ่บนเว็บถูกเข้ารหัสในฟอร์แมต YUV เช่น I420 'Y' plane เป็นตัวแทนภาพระดับสีเทาที่สมบูรณ์ของภาพ เราสามารถดึงเฉพาะ plane นี้ออกมาและแสดงผลบน canvas ได้

async function displayGrayscale(videoFrame) {
  // เราสมมติว่า videoFrame อยู่ในฟอร์แมต YUV เช่น 'I420' หรือ 'NV12'
  if (!videoFrame.format.startsWith('I4')) {
    console.error('This example requires a YUV 4:2:0 planar format.');
    videoFrame.close();
    return;
  }

  const yPlaneInfo = videoFrame.layout[0]; // Y plane จะอยู่ลำดับแรกเสมอ

  // สร้างบัฟเฟอร์เพื่อเก็บข้อมูลเฉพาะ Y plane
  const yPlaneData = new Uint8Array(yPlaneInfo.stride * videoFrame.codedHeight);

  // คัดลอก Y plane ลงในบัฟเฟอร์ของเรา
  await videoFrame.copyTo(yPlaneData, {
    rect: { x: 0, y: 0, width: videoFrame.codedWidth, height: videoFrame.codedHeight },
    layout: [yPlaneInfo]
  });

  // ตอนนี้ yPlaneData มีข้อมูลพิกเซลระดับสีเทาดิบอยู่
  // เราต้องแสดงผลมัน เราจะสร้างบัฟเฟอร์ RGBA สำหรับ canvas
  const canvas = document.getElementById('my-canvas');
  canvas.width = videoFrame.displayWidth;
  canvas.height = videoFrame.displayHeight;
  const ctx = canvas.getContext('2d');
  const imageData = ctx.createImageData(canvas.width, canvas.height);

  // วนลูปผ่านพิกเซลของ canvas และเติมข้อมูลจาก Y plane
  for (let y = 0; y < videoFrame.displayHeight; y++) {
    for (let x = 0; x < videoFrame.displayWidth; x++) {
      // สำคัญ: ใช้ stride เพื่อหาดัชนีต้นทางที่ถูกต้อง!
      const yIndex = y * yPlaneInfo.stride + x;
      const luma = yPlaneData[yIndex];

      // คำนวณดัชนีปลายทางในบัฟเฟอร์ RGBA ImageData
      const rgbaIndex = (y * canvas.width + x) * 4;

      imageData.data[rgbaIndex] = luma;     // แดง
      imageData.data[rgbaIndex + 1] = luma; // เขียว
      imageData.data[rgbaIndex + 2] = luma; // น้ำเงิน
      imageData.data[rgbaIndex + 3] = 255;  // อัลฟ่า
    }
  }

  ctx.putImageData(imageData, 0, 0);

  // สำคัญมาก: ต้องปิด VideoFrame เสมอเพื่อปล่อยหน่วยความจำ
  videoFrame.close();
}

ตัวอย่างนี้เน้นขั้นตอนสำคัญหลายอย่าง: การระบุ layout ของ plane ที่ถูกต้อง, การจัดสรรบัฟเฟอร์ปลายทาง, การใช้ copyTo เพื่อดึงข้อมูล, และการวนลูปผ่านข้อมูลอย่างถูกต้องโดยใช้ stride เพื่อสร้างภาพใหม่

ตัวอย่างที่ 2: การจัดการข้อมูลในที่ (In-Place Manipulation) (ฟิลเตอร์ซีเปีย)

ตอนนี้เรามาลองจัดการข้อมูลโดยตรงกัน ฟิลเตอร์ซีเปียเป็นเอฟเฟกต์คลาสสิกที่นำไปใช้ได้ง่าย สำหรับตัวอย่างนี้ การทำงานกับเฟรม RGBA จะง่ายกว่า ซึ่งคุณอาจได้รับมาจาก canvas หรือ WebGL context

async function applySepiaFilter(videoFrame) {
  // ตัวอย่างนี้สมมติว่าเฟรมอินพุตเป็น 'RGBA' หรือ 'BGRA'
  if (videoFrame.format !== 'RGBA' && videoFrame.format !== 'BGRA') {
    console.error('Sepia filter example requires an RGBA frame.');
    videoFrame.close();
    return null;
  }

  // จัดสรรบัฟเฟอร์เพื่อเก็บข้อมูลพิกเซล
  const frameDataSize = videoFrame.allocationSize();
  const frameData = new Uint8Array(frameDataSize);
  await videoFrame.copyTo(frameData);

  const layout = videoFrame.layout[0]; // RGBA เป็น plane เดียว

  // ตอนนี้จัดการข้อมูลในบัฟเฟอร์
  for (let y = 0; y < videoFrame.codedHeight; y++) {
    for (let x = 0; x < videoFrame.codedWidth; x++) {
      const pixelIndex = y * layout.stride + x * 4; // 4 ไบต์ต่อพิกเซล (R,G,B,A)

      const r = frameData[pixelIndex];
      const g = frameData[pixelIndex + 1];
      const b = frameData[pixelIndex + 2];

      const tr = 0.393 * r + 0.769 * g + 0.189 * b;
      const tg = 0.349 * r + 0.686 * g + 0.168 * b;
      const tb = 0.272 * r + 0.534 * g + 0.131 * b;

      frameData[pixelIndex] = Math.min(255, tr);
      frameData[pixelIndex + 1] = Math.min(255, tg);
      frameData[pixelIndex + 2] = Math.min(255, tb);
      // อัลฟ่า (frameData[pixelIndex + 3]) ไม่เปลี่ยนแปลง
    }
  }

  // สร้าง VideoFrame *ใหม่* ด้วยข้อมูลที่แก้ไขแล้ว
  const newFrame = new VideoFrame(frameData, {
    format: videoFrame.format,
    codedWidth: videoFrame.codedWidth,
    codedHeight: videoFrame.codedHeight,
    timestamp: videoFrame.timestamp,
    duration: videoFrame.duration
  });

  // อย่าลืมปิดเฟรมต้นฉบับ!
  videoFrame.close();

  return newFrame;
}

สิ่งนี้แสดงให้เห็นวงจรการอ่าน-แก้ไข-เขียนที่สมบูรณ์: คัดลอกข้อมูลออกมา, วนลูปผ่านข้อมูลโดยใช้ stride, ใช้การแปลงทางคณิตศาสตร์กับแต่ละพิกเซล, และสร้าง VideoFrame ใหม่ด้วยข้อมูลผลลัพธ์ เฟรมใหม่นี้สามารถนำไปแสดงผลบน canvas, ส่งไปยัง VideoEncoder, หรือส่งต่อไปยังขั้นตอนการประมวลผลอื่นได้

ประสิทธิภาพเป็นสิ่งสำคัญ: JavaScript เทียบกับ WebAssembly (WASM)

การวนลูปผ่านพิกเซลนับล้านในทุกเฟรม (เฟรม 1080p มีมากกว่า 2 ล้านพิกเซล หรือ 8 ล้านจุดข้อมูลใน RGBA) ใน JavaScript อาจทำงานได้ช้า แม้ว่า JS engines สมัยใหม่จะเร็วอย่างไม่น่าเชื่อ แต่สำหรับการประมวลผลวิดีโอความละเอียดสูง (HD, 4K) แบบเรียลไทม์ แนวทางนี้สามารถทำให้ main thread ทำงานหนักเกินไปได้อย่างง่ายดาย ซึ่งนำไปสู่ประสบการณ์ผู้ใช้ที่กระตุก

นี่คือจุดที่ WebAssembly (WASM) กลายเป็นเครื่องมือที่จำเป็น WASM ช่วยให้คุณสามารถรันโค้ดที่เขียนด้วยภาษาต่างๆ เช่น C++, Rust หรือ Go ด้วยความเร็วใกล้เคียงกับ native ภายในเบราว์เซอร์ ขั้นตอนการทำงานสำหรับการประมวลผลวิดีโอจะกลายเป็น:

1. ใน JavaScript: ใช้ videoFrame.copyTo() เพื่อรับข้อมูลพิกเซลดิบลงใน ArrayBuffer
2. ส่งต่อไปยัง WASM: ส่งการอ้างอิงไปยังบัฟเฟอร์นี้เข้าไปในโมดูล WASM ที่คอมไพล์แล้วของคุณ นี่เป็นการดำเนินการที่รวดเร็วมากเนื่องจากไม่ต้องคัดลอกข้อมูล
3. ใน WASM (C++/Rust): รันอัลกอริทึมการประมวลผลภาพที่ปรับให้เหมาะสมที่สุดของคุณโดยตรงบนบัฟเฟอร์หน่วยความจำ ซึ่งเร็วกว่าการวนลูปใน JavaScript หลายเท่าตัว
4. กลับมาที่ JavaScript: เมื่อ WASM ทำงานเสร็จ การควบคุมจะกลับมาที่ JavaScript จากนั้นคุณสามารถใช้บัฟเฟอร์ที่แก้ไขแล้วเพื่อสร้าง VideoFrame ใหม่

สำหรับแอปพลิเคชันการจัดการวิดีโอแบบเรียลไทม์ที่จริงจังใดๆ—เช่น พื้นหลังเสมือน, การตรวจจับวัตถุ, หรือฟิลเตอร์ที่ซับซ้อน—การใช้ประโยชน์จาก WebAssembly ไม่ใช่แค่ทางเลือก แต่เป็นสิ่งจำเป็น

การจัดการ Pixel Formats ที่แตกต่างกัน (เช่น I420, NV12)

แม้ว่า RGBA จะเรียบง่าย แต่ส่วนใหญ่คุณจะได้รับเฟรมในฟอร์แมต YUV แบบระนาบจาก VideoDecoder มาดูวิธีจัดการกับฟอร์แมต planar เต็มรูปแบบอย่าง I420 กัน

VideoFrame ในฟอร์แมต I420 จะมี layout descriptors สามตัวในอาร์เรย์ layout ของมัน:

• layout[0]: Y plane (luma) ขนาดคือ codedWidth x codedHeight
• layout[1]: U plane (chroma) ขนาดคือ codedWidth/2 x codedHeight/2
• layout[2]: V plane (chroma) ขนาดคือ codedWidth/2 x codedHeight/2

นี่คือวิธีที่คุณจะคัดลอกทั้งสาม planes ลงในบัฟเฟอร์เดียว:

async function extractI420Planes(videoFrame) {
  const totalSize = videoFrame.allocationSize({ format: 'I420' });
  const allPlanesData = new Uint8Array(totalSize);

  const layouts = await videoFrame.copyTo(allPlanesData);

  // layouts เป็นอาร์เรย์ของอ็อบเจกต์ PlaneLayout 3 ตัว
  console.log('Y Plane Layout:', layouts[0]); // { offset: 0, stride: ... }
  console.log('U Plane Layout:', layouts[1]); // { offset: ..., stride: ... }
  console.log('V Plane Layout:', layouts[2]); // { offset: ..., stride: ... }

  // ตอนนี้คุณสามารถเข้าถึงแต่ละ plane ภายในบัฟเฟอร์ `allPlanesData`
  // โดยใช้ offset และ stride เฉพาะของมัน

  const yPlaneView = new Uint8Array(
    allPlanesData.buffer,
    layouts[0].offset,
    layouts[0].stride * videoFrame.codedHeight
  );

  // โปรดทราบว่าขนาดของ chroma จะเป็นครึ่งหนึ่ง!
  const uPlaneView = new Uint8Array(
    allPlanesData.buffer,
    layouts[1].offset,
    layouts[1].stride * (videoFrame.codedHeight / 2)
  );

  const vPlaneView = new Uint8Array(
    allPlanesData.buffer,
    layouts[2].offset,
    layouts[2].stride * (videoFrame.codedHeight / 2)
  );

  console.log('Accessed Y plane size:', yPlaneView.byteLength);
  console.log('Accessed U plane size:', uPlaneView.byteLength);

  videoFrame.close();
}

อีกฟอร์แมตที่พบบ่อยคือ NV12 ซึ่งเป็นแบบ semi-planar มันมีสอง planes: หนึ่งสำหรับ Y, และ plane ที่สองซึ่งค่า U และ V ถูกสอดแทรกกัน (interleaved) (เช่น [U1, V1, U2, V2, ...]) WebCodecs API จัดการเรื่องนี้อย่างโปร่งใส; VideoFrame ในฟอร์แมต NV12 จะมี layouts สองตัวในอาร์เรย์ layout ของมัน

ความท้าทายและแนวทางปฏิบัติที่ดีที่สุด

การทำงานในระดับต่ำนี้มีประสิทธิภาพ แต่ก็มาพร้อมกับความรับผิดชอบ

การจัดการหน่วยความจำเป็นสิ่งสำคัญที่สุด

VideoFrame เก็บหน่วยความจำจำนวนมาก ซึ่งมักจะถูกจัดการนอก heap ของ garbage collector ของ JavaScript หากคุณไม่ปล่อยหน่วยความจำนี้อย่างชัดเจน คุณจะทำให้เกิดหน่วยความจำรั่วไหล (memory leak) ซึ่งอาจทำให้แท็บเบราว์เซอร์ล่มได้

ต้องเรียกใช้ videoFrame.close() เสมอ เมื่อคุณใช้งานเฟรมเสร็จแล้ว

ลักษณะการทำงานแบบ Asynchronous

การเข้าถึงข้อมูลทั้งหมดเป็นแบบอะซิงโครนัส สถาปัตยกรรมของแอปพลิเคชันของคุณต้องจัดการกับโฟลว์ของ Promises และ async/await อย่างเหมาะสมเพื่อหลีกเลี่ยง race conditions และรับประกันว่าไปป์ไลน์การประมวลผลจะราบรื่น

ความเข้ากันได้ของเบราว์เซอร์

WebCodecs เป็น API ที่ทันสมัย แม้ว่าจะรองรับในเบราว์เซอร์หลักทั้งหมด แต่ควรตรวจสอบความพร้อมใช้งานของมันเสมอ และระวังรายละเอียดการใช้งานหรือข้อจำกัดเฉพาะของผู้ให้บริการแต่ละราย ใช้การตรวจจับคุณสมบัติ (feature detection) ก่อนพยายามใช้ API

สรุป: พรมแดนใหม่สำหรับวิดีโอบนเว็บ

ความสามารถในการเข้าถึงและจัดการข้อมูล plane ดิบของ VideoFrame โดยตรงผ่าน WebCodecs API ถือเป็นการเปลี่ยนแปลงกระบวนทัศน์สำหรับแอปพลิเคชันสื่อบนเว็บ มันขจัดกล่องดำขององค์ประกอบ <video> และให้นักพัฒนามีการควบคุมที่ละเอียดซึ่งก่อนหน้านี้สงวนไว้สำหรับแอปพลิเคชัน native เท่านั้น

ด้วยการทำความเข้าใจพื้นฐานของโครงสร้างหน่วยความจำวิดีโอ—planes, stride และ color formats—และโดยการใช้ประโยชน์จากพลังของ WebAssembly สำหรับการดำเนินงานที่ต้องการประสิทธิภาพสูง ตอนนี้คุณสามารถสร้างเครื่องมือประมวลผลวิดีโอที่ซับซ้อนอย่างไม่น่าเชื่อได้โดยตรงในเบราว์เซอร์ ตั้งแต่การปรับแก้สีแบบเรียลไทม์และเอฟเฟกต์ภาพที่กำหนดเอง ไปจนถึง machine learning ฝั่งไคลเอ็นต์และการวิเคราะห์วิดีโอ ความเป็นไปได้นั้นกว้างใหญ่ไพศาล ยุคของวิดีโอประสิทธิภาพสูงระดับต่ำบนเว็บได้เริ่มต้นขึ้นแล้วอย่างแท้จริง